See how varnish software compares to other vendors in security performance
https://vinyl-cache.org/security/VSV00019.html says: Originally published 2026-05-18, last updated 2026-06-28
CVE-2026-50052
A deficiency in HTTP/2 request parsing can be exploited to launch a backend request desync attack (request smuggling), which in turn can be used for cache poisoning, authentication bypass or possibly even information disclosure and manipulation.
The attack vector only exists if HTTP/2 support is enabled by setting the feature parameter to contain +http2. HTTP/2 support is disabled by default.
We recommend to upgrade to a version which is not affected, to disable HTTP/2 support or to mitigate the issue in VCL, as detailed below.
Versions affected
- Vinyl Cache 9.0.0
- Varnish Cache by Varnish Software up to and including 9.0.2
- All Varnish Cache Releases from 7.6.0 up to and including 8.0.1
- Varnish Cache 6.0 LTS series from 6.0.14 up to and including 6.0.17.
Versions not affected
- Vinyl Cache 9.0.1 (released 2026-05-18)
- Vinyl Cache main branch at commit dfc27fb4e7bf110945f5c145ce95b8de14ead77f or later
- Varnish Cache by Varnish Software 9.0.3 (released 2026-05-18)
- Varnish Cache 8.0.2 (released 2026-05-18)
- Varnish Cache 6.0 LTS version 6.0.18 (2026-05-18)
- Varnish Enterprise by Varnish Software
Mitigation Options
Several options to mitigate this issue exist. The safest is disabling HTTP/2. [See https://vinyl-cache.org/security/VSV00019.html for full details.] Acknowledgements and credits
We thank Lam Jun Rong of Calif.io, who used Anthropic Research’s tool “Claude”, for reporting this issue.
For the Vinyl Cache project, the issue has been handled by Nils Goroll of UPLEX. The merged fix is a slight variation of the proposed fix by Lam Jun Rong, which had already been found independently by Dridi Boukelmoune. https://blog.calif.io/p/mad-bugs-my-cousin-vinyl-cve-2026 provides the story of how it was found by the researcher.
Varnish Cache 9 before 9.0.1 allows a "workspace overflow" denial of service (daemon panic) after timeoutlinger. A malicious client could send an HTTP/1 request, wait long enough until the session releases its worker thread (timeoutlinger) and resume traffic before the session is closed (timeoutidle) sending more than one request at once to trigger a pipelining operation between requests. This vulnerability affecting Varnish Cache 9.0.0 emerged from a port of the Varnish Enterprise non-blocking architecture for HTTP/2. New code was needed to adapt to a more recent workspace API that formalizes the pipelining operation. In addition to the workspace change on the Varnish Cache side, other differences created merge conflicts, like partial support for trailers in Varnish Enterprise. The conflict resolution missed one code path configuring pipelining to perform a complete workspace rollback, losing the guarantee that prefetched data would fit inside workspaceclient during the transition from one request to the next. This can result in a workspace overflow, triggering a panic and crashing the Varnish server.
Varnish Enterprise before 6.0.16r12 allows a "workspace overflow" denial of service (daemon panic) for shared VCL. The headerplus.writereq0() function from vmodheaderplus updates the underlying req0, which is normally the original read-only request from which req is derived (readable and writable from VCL). This is useful in the active VCL, after amending req, to prepare a refined req0 before switching to a different VCL with the return (vcl(<label>)) action. This is for example how the Varnish Controller operates shared VCL deployments. If the amended req contained too many header fields for req0, this would have resulted in a workspace overflow that would in turn trigger a panic and crash the Varnish Enterprise server. This could be used as a Denial of Service attack vector by malicious clients.
Varnish Cache 9 before 9.0.1 and Varnish Enterprise before 6.0.16r11 allows a "workspace overflow" denial of service (daemon panic) for certain amounts of prefetched data. The setup of an HTTP/2 session starts with a speculative HTTP/1 transport, and upon upgrading to h2 the HTTP/1 request is repurposed as stream zero. During the upgrade, a buffer allocation is made to reserve space to send frames to the client. This allocation would split the original workspace, and depending on the amount of prefetched data, the next fetch could perform a pipelining operation that would run out of workspace.
Varnish Cache before 8.0.1 and Varnish Enterprise before 6.0.16r12, in certain unchecked req.url scenarios, mishandle URLs with a path of / for HTTP/1.1, potentially leading to cache poisoning or authentication bypass.
End of life: 9/15/2026, Latest version: 8.0.0
Hello Asad,
Is any CVE already assigned after the announcement was sent? If not I can provide a CVE identifier if needed.
Thanks,
Marco Benatto Red Hat Product Security secalert () redhat com for urgent response
On Tue, May 13, 2025 at 12:23 PM Asad Ahmed <asadsa () varnish-software com> wrote: Hello there,
We released Varnish Cache 7.7.1, 7.6.3, and 6.0.14 yesterday (sorry for the delay).
These releases fixes a vulnerability reported to us, which got the name VSV00016.
CVE: Not assigned yet, expect a follow-up here.
A client-side desync vulnerability can be triggered in Varnish Cache. This vulnerability can be triggered under specific circumstances involving malformed HTTP/1 chunked requests.
An attacker can abuse a flaw in Varnish’s handling of chunked transfer encoding which allows certain malformed HTTP/1 requests to exploit improper framing of the message body to smuggle additional requests. Specifically, Varnish incorrectly permits CRLF to be skipped to delimit chunk boundaries. Impact <https://varnish-cache.org/security/VSV00016.html#impact>
The primary risk of this vulnerability is enabling HTTP request smuggling attacks, which could have consequences for downstream systems. Specifically:
Cache Poisoning: A downstream cache positioned in front of Varnish could cache incorrect or malicious content if it allows the aforementioned malformed HTTP/1 requests to pass through unhandled. This can lead to unintended responses being served to users, potentially exposing sensitive information or delivering harmful payloads.
Security Risks: Bypass of WAF type products downstream from Varnish could be achieved if these products are configured to not inspect request bodies and in addition allow the aforementioned malformed HTTP/1 requests to pass through.
The vulnerability has been given a severity rating of low/medium. Versions affected <https://varnish-cache.org/security/VSV00016.html#versions-affected>
-
Varnish Cache releases up to and including 7.7.0. -
Varnish Cache 6.0 LTS series up to and including 6.0.13.
Versions not affected <https://varnish-cache.org/security/VSV00016.html#versions-not-affected>
-
Varnish Cache 7.7.1 (released 2025-05-12) -
Varnish Cache 7.6.3 (released 2025-05-12) -
Varnish Cache 6.0 LTS version 6.0.14 (released 2025-05-12)
Solution <https://varnish-cache.org/security/VSV00016.html#solution>
The recommended solution is to upgrade Varnish to one of the versions where this issue has been resolved, and then ensure that Varnish is restarted. Thankyous and credits <https://varnish-cache.org/security/VSV00016.html#thankyous-and-credits>
Ben Kallus at Dartmouth College for finding and reporting the issue to the project in a responsible manner. Nils Goroll (UPLEX), Dridi Boukelmoune (Varnish Software) and Poul-Henning Kamp for the patches. Varnish Software for handling this security incident.
References:
- https://varnish-cache.org/security/VSV00016.html#vsv00016 - https://varnish-cache.org/security/index.html - https://varnish-cache.org/lists/pipermail/varnish-announce/2025-May/000767.html - https://github.com/varnishcache/varnish-cache - https://varnish-cache.org/releases/rel7.7.1.html#rel7-7-1 - https://varnish-cache.org/releases/rel7.6.3.html#rel7-6-3 - https://varnish-cache.org/releases/rel6.0.14.html#rel6-0-14
-- Asad
Hello there,
We released Varnish Cache 7.7.1, 7.6.3, and 6.0.14 yesterday (sorry for the delay).
These releases fixes a vulnerability reported to us, which got the name VSV00016.
CVE: Not assigned yet, expect a follow-up here.
A client-side desync vulnerability can be triggered in Varnish Cache. This vulnerability can be triggered under specific circumstances involving malformed HTTP/1 chunked requests.
An attacker can abuse a flaw in Varnish’s handling of chunked transfer encoding which allows certain malformed HTTP/1 requests to exploit improper framing of the message body to smuggle additional requests. Specifically, Varnish incorrectly permits CRLF to be skipped to delimit chunk boundaries. Impact <https://varnish-cache.org/security/VSV00016.html#impact>
The primary risk of this vulnerability is enabling HTTP request smuggling attacks, which could have consequences for downstream systems. Specifically:
Cache Poisoning: A downstream cache positioned in front of Varnish could cache incorrect or malicious content if it allows the aforementioned malformed HTTP/1 requests to pass through unhandled. This can lead to unintended responses being served to users, potentially exposing sensitive information or delivering harmful payloads.
Security Risks: Bypass of WAF type products downstream from Varnish could be achieved if these products are configured to not inspect request bodies and in addition allow the aforementioned malformed HTTP/1 requests to pass through.
The vulnerability has been given a severity rating of low/medium. Versions affected <https://varnish-cache.org/security/VSV00016.html#versions-affected>
-
Varnish Cache releases up to and including 7.7.0. -
Varnish Cache 6.0 LTS series up to and including 6.0.13.
Versions not affected <https://varnish-cache.org/security/VSV00016.html#versions-not-affected>
-
Varnish Cache 7.7.1 (released 2025-05-12) -
Varnish Cache 7.6.3 (released 2025-05-12) -
Varnish Cache 6.0 LTS version 6.0.14 (released 2025-05-12)
Solution <https://varnish-cache.org/security/VSV00016.html#solution>
The recommended solution is to upgrade Varnish to one of the versions where this issue has been resolved, and then ensure that Varnish is restarted. Thankyous and credits <https://varnish-cache.org/security/VSV00016.html#thankyous-and-credits>
Ben Kallus at Dartmouth College for finding and reporting the issue to the project in a responsible manner. Nils Goroll (UPLEX), Dridi Boukelmoune (Varnish Software) and Poul-Henning Kamp for the patches. Varnish Software for handling this security incident.
References:
- https://varnish-cache.org/security/VSV00016.html#vsv00016 - https://varnish-cache.org/security/index.html - https://varnish-cache.org/lists/pipermail/varnish-announce/2025-May/000767.html - https://github.com/varnishcache/varnish-cache - https://varnish-cache.org/releases/rel7.7.1.html#rel7-7-1 - https://varnish-cache.org/releases/rel7.6.3.html#rel7-6-3 - https://varnish-cache.org/releases/rel6.0.14.html#rel6-0-14
-- Asad
End of life: 3/15/2026, Latest version: 7.7.3
End of life: 9/15/2025, Latest version: 7.6.5
End of life: 9/15/2025, Latest version: 7.6.5
End of life: 3/15/2025, Latest version: 7.5.0
End of life: 3/15/2025, Latest version: 7.5.0
End of life: 9/15/2024, Latest version: 7.4.3
End of life: 9/15/2024, Latest version: 7.4.3
End of life: 3/15/2024, Latest version: 7.3.2
End of life: 3/15/2024, Latest version: 7.3.2
End of life: 9/15/2023, Latest version: 7.2.1
End of life: 9/15/2023, Latest version: 7.2.1
End of life: 3/15/2023, Latest version: 7.1.2
End of life: 3/15/2023, Latest version: 7.1.2
End of life: 9/15/2022, Latest version: 7.0.3
End of life: 9/15/2022, Latest version: 7.0.3
Latest version: 6.0.16
Latest version: 6.0.16